In modern software designs, interconnectivities with various data or service providers are important, if not a critical aspect. With the convenience and openness of the Internet, software program products can no longer be operable without extensive connectivity with other devices or programs. At the programming level, software program products communicate with one another via application program interfaces (APIs) to properly and, sometimes securely, exchange data between different software program products. Software developers sometimes create special tools or “plug-ins” to leverage data communicated via the APIs to provide special features to the user. These tools or “plug-ins” usually need to create transaction requests to the APIs that are accepted by the APIs in order to fully leverage the functionality of the APIs.
Consequently, APIs designers frequently publish manuals, papers, tutorials describing structures of the APIs. For example, the APIs manuals, papers, or tutorials such as the ones shown in FIGS. 1 and 2 typically list the names of specific properties that are accepted by the APIs in one column or one side 202 while showing an example on the other side 204. Similarly, FIG. 2 shows another kind of API tutorial in windows 202 and 204 describing how a developer would create a properly configured requests or programming instructions to the APIs. FIG. 3A, shows another prior art user interface approach with a user request pane 352 is disposed or configured to be displayed above a response pane 354.
Therefore, it is acceptable to software developers to go through these static lists, tables, illustrations, tutorials, examples, etc., before begin to code their desirable API requests or instructions.
However, the longstanding problems occur when the developers are ready to submit their requests or instructions to the APIs to determine whether the requests or instructions are valid. Many times, the developers need to complete a full and complete request or instruction before submitting, but the validation response may not provide a detailed report other than a “SUCCESS” or a “FAIL” feedback.
If the response is a “FAIL”, this requires the developers to go back to the drawing board, trying to figure out which part of the their requests or instructions failed. For example, they would again review the APIs manuals or tutorials to make sure their requests or instructions have complied with the required syntax, property limitations, parameter sizes, etc. Once they confirm again that they have the right request, they will resubmit again for validation. This process will repeat itself until the validation response indicates “SUCCESS”.